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Abstract 


This document defines how to use the WebRTC data channel mechanism to realize a data 
channel, referred to as a Controlling Multiple Streams for Telepresence (CLUE) data channel, for 
transporting CLUE protocol messages between two CLUE entities. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for examination, 
experimental implementation, and evaluation. 


This document defines an Experimental Protocol for the Internet community. This document is a 
product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF 
community. It has received public review and has been approved for publication by the Internet 
Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for 
any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc8850. 


Copyright Notice 


Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. Code Components extracted from this document must include 
Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Simplified BSD License. 
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1. Introduction 


This document defines how to use the WebRTC data channel mechanism [RFC8831] to realize a 
data channel, referred to as a Controlling Multiple Streams for Telepresence (CLUE) data 
channel, for transporting CLUE protocol messages [RFC8847] between two CLUE entities. 


This document also defines how to describe the SCTPoDTLS association [RFC8261] (also referred 
to as "SCTP over DTLS" in this document) used to realize the CLUE data channel using the Session 
Description Protocol (SDP) [RFC4566] and defines usage of the SDP-based "SCTP over DTLS" data 
channel negotiation mechanism [RFC8864]. ("SCTP" stands for "Stream Control Transmission 
Protocol".) This includes SCTP considerations specific to a CLUE data channel, the SDP media 
description ("m=" line) values, and usage of SDP attributes specific to a CLUE data channel. 


Details and procedures associated with the CLUE protocol, and the SDP Offer/Answer procedures 
[RFC3264] for negotiating usage of a CLUE data channel, are outside the scope of this document. 


NOTE: The usage of the Data Channel Establishment Protocol (DCEP) [RFC8832] for 
establishing a CLUE data channel is outside the scope of this document. 


2. Conventions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


SCTPODTLS association 
Refers to an SCTP association carried over a DTLS connection [RFC8261]. 


WebRTC data channel 
Refers to a pair of SCTP streams over an SCTPoDTLS association that is used to transport non- 
media data between two entities, as defined in [RFC8831]. 


CLUE data channel 
Refers to a WebRTC data channel realization [RFC8831], with a specific set of SCTP 
characteristics, with the purpose of transporting CLUE protocol messages [RFC8847] between 
two CLUE entities. 


CLUE entity 
Refers to a SIP User Agent (UA) [RFC3261] that supports the CLUE data channel and the CLUE 
protocol. 


CLUE session 
Refers to a SIP session [RFC3261] between two SIP UAs, where a CLUE data channel, 
associated with the SIP session, has been established between the SIP UAs. 
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SCTP stream 
Defined in [RFC4960] as a unidirectional logical channel established from one to another 
associated SCTP endpoint, within which all user messages are delivered in sequence except 
for those submitted to the unordered delivery service. 


SCTP stream identifier 
Defined in [RFC4960] as an unsigned integer. Identifies an SCTP stream. 


3. CLUE Data Channel 


3.1. General 


This section describes the realization of a CLUE data channel, using the WebRTC data channel 
mechanism. This includes a set of SCTP characteristics specific to a CLUE data channel, the values 
of the "m=" line describing the SCTPoDTLS association associated with the WebRTC data channel, 
and the usage of the SDP-based "SCTP over DTLS" data channel negotiation mechanism for 
creating the CLUE data channel. 


As described in [RFC8831], the SCTP streams realizing a WebRTC data channel must be associated 
with the same SCTP association. In addition, both SCTP streams realizing the WebRTC data 
channel must use the same SCTP stream identifier value. These rules also apply to a CLUE data 
channel. 


Within a given CLUE session, a CLUE entity MUST use a single CLUE data channel for transport of 
all CLUE messages towards its peer. 


3.2. SCTP Considerations 


3.2.1. General 


As described in [RFC8831], different SCTP options (e.g., regarding ordered delivery) can be used 
for a data channel. This section describes the SCTP options used for a CLUE data channel. Section 
3.3 describes how SCTP options are signaled using SDP. 


3.2.2. SCTP Payload Protocol Identifier (PPID) 


A CLUE entity MUST use the PPID value 51 when sending a CLUE message on a CLUE data 
channel. 


NOTE: As described in [RFC8831], the PPID value 51 indicates that the SCTP message 
contains data encoded in UTF-8 format. The PPID value 51 does not indicate which 
application protocol the SCTP message is associated with -- only the format in which 
the data is encoded. 


3.2.3. Reliability 


The usage of SCTP for the CLUE data channel ensures reliable transport of CLUE protocol 
messages [RFC8847]. 
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[RFC8831] requires the support of the partial reliability extension defined in [RFC3758] and the 
limited retransmission policy defined in [RFC7496]. A CLUE entity MUST NOT use these 
extensions, as messages are required to always be sent reliably. A CLUE entity MUST terminate 
the session if it detects that the peer entity uses any of the extensions. 


3.2.4. Order 

A CLUE entity MUST use the ordered delivery SCTP service, as described in [RFC4960], for the 
CLUE data channel. 

3.2.5. Stream Reset 

A CLUE entity MUST support the stream reset extension defined in [RFC6525]. 

Per [RFC8831], the dynamic address reconfiguration extension parameter (‘Supported Extensions 
Parameter’) defined in [RFC5061] must be used to signal the support of the stream reset 
extension defined in [RFC6525]. Other features defined in [RFC5061] MUST NOT be used for CLUE 
data channels. 

3.2.6. SCTP Multihoming 

SCTP multihoming is not supported for SCTPoDTLS associations and therefore cannot be used for 
a CLUE data channel. 

3.2.7. Closing the CLUE Data Channel 


As described in [RFC8831], to close a data channel, an entity sends an SCTP reset message 
[RFC6525] on its outgoing SCTP stream associated with the data channel. When the remote peer 
receives the reset message, it also sends (unless already sent) a reset message on its outgoing 
SCTP stream associated with the data channel. The SCTPoDTLS association, and other data 
channels established on the same association, are not affected by the SCTP reset messages. 


3.3. SDP Considerations 
3.3.1. General 


This section defines how to (1) construct the SDP media description ("m=" line) for describing the 
SCTPoDTLS association used to realize a CLUE data channel and (2) use the SDP-based "SCTP over 
DTLS" data channel negotiation mechanism [RFC8864] for establishing a CLUE data channel on 
the SCTPoDTLS association. 


NOTE: Protocols other than SDP for negotiating usage of an SCTPoDTLS association 
for realizing a CLUE data channel are outside the scope of this specification. 


[RFC8848] describes the SDP Offer/Answer procedures for negotiating a CLUE session, including 
the CLUE-controlled media streams and the CLUE data channel. 


3.3.1.1. SDP Media Description Fields 


[RFC8841] defines how to set the values of an "m=" line describing an SCTPoDTLS association. As 
defined in [RFC8841], for a CLUE data channel the values are set as follows: 
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media port proto fmt 
"application" UDP port value "UDP/DTLS/SCTP" "webrtc-datachannel" 


"application" TCP port value "TCP/DTLS/SCTP" "webrtc-datachannel" 
Table 1: SDP "proto" Field Values 


CLUE entities SHOULD NOT transport the SCTPoDTLS association used to realize the CLUE data 
channel over TCP (using the "TCP/DTLS/SCTP" proto value), unless it is known that UDP/DTLS/ 
SCTP will not work (for instance, when the Interactive Connectivity Establishment (ICE) 
mechanism [RFC8445] is used and the ICE procedures determine that TCP transport is required). 


3.3.1.2. SDP sctp-port Attribute 
As defined in [RFC8841], the SDP sctp-port attribute value is set to the SCTP port of the 


SCTPODTLS association. A CLUE entity can choose any valid SCTP port value [RFC8841]. 
3.3.2. SDP dcmap Attribute 


The values of the SDP dcmap attribute [RFC8864], associated with the "m=" line describing the 
SCTPODTLS association used to realize the WebRTC data channel, are set as follows: 


stream-id subprotocol label ordered max- max- 
retr time 
Value of the SCTP stream ECLUE: Application "true" N/A N/A 
used to realize the CLUE specific 


data channel 
Table 2: SDP dcmap Attribute Values 
NOTE: As CLUE entities are required to use ordered SCTP message delivery, with full 


reliability, according to the procedures in [RFC8864] the max-retr and max-time 
attribute parameters are not used when negotiating CLUE data channels. 


3.3.3. SDP dcsa Attribute 
The SDP dcsa attribute [RFC8864] is not used when establishing a CLUE data channel. 


3.3.4. Example 


The example in Figure 1 shows an SDP media description for a CLUE data channel. Complete SDP 
examples can be found in [RFC8848]. 
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m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 
a=sctp-port: 5000 
a=dcmap:2 subprotocol="CLUE" ;ordered=true 


Figure 1: SDP Media Description for a CLUE Data Channel 


4. Security Considerations 


This specification relies on the security properties of the WebRTC data channel described in 
[RFC8831], including reliance on DTLS. Since CLUE sessions are established using SIP/SDP, 
protecting the data channel against message modification and recovery requires the use of SIP 
authentication and authorization mechanisms described in [RFC3261] for session establishment 
prior to establishing the data channel. 


5. IANA Considerations 


5.1. Subprotocol Identifier "clue" 


This document adds the subprotocol identifier "clue" to the "WebSocket Subprotocol Name 
Registry" as follows: 


Subprotocol Identifier clue 
Subprotocol Common Name CLUE 
Subprotocol Definition RFC 8850 


Reference RFC 8850 


Table 3: Registration of 'clue' Value 
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